1. Field of the Invention
The present invention relates to the process of creating a build on a computing device. More specifically, the present invention involves the use of files that are checked out of a version control system. These files enable the user to control server class configurations in the computing device from a file on a PC. The files enable the user to dynamically configure server classes with respect to the particular environment in which it is desired that the server class run in, and delete previous server-class configurations in order that corruption, which might be due to preexisting server classes in the pathway, is prevented.
2. Description of the Related Art
Version control systems, also known as source control tools, are a component of configuration management. The purpose for these tools is to enable a computer programmer to take a “snapshot” of a development process to be recovered at some stage in the future. Recovery of the snapshot usually occurs when computer program application development has moved on past the snapshot time.
If a source control tool is not used, and software is released for use in the field without maintaining a version, problems may arise when later software releases are made. If the program with the later release contains a bug that prevents the software from being useable, without the use of a version controlling system, there is no way to recover specifically which version in which the bug exists.
Bugs usually develop at the point that software is modified. Oftentimes the bug is not recognized until long after the modification is made. Therefore, version control tools enable programmers to easily retrieve old versions to see the point and time at which the bug entered the application's development.
One common version control system known to those skilled in the art is known as “CVS.” CVS stores all of the versions of each file which comprises an application. This is done, however, in a manner in which only the differences between the versions of each file are stored. If a number of different programmers are working on the same application, it is very easy for different programmers to overwrite the changes of another programmer unless extreme caution is taken. CVS overcomes this problem by isolating the different application developers by a wall. Each of the programmers works in his or her own directory, and afterwards CVS combines all of the changes made by all of the developers when each of them finishes work.
The place at which CVS maintains all of the changes to the application is referred to as a repository. When a programmer works on an application, working files are checked out of the repository. When the programmer is finished, the changes are checked back in. The repository then includes all the changes the programmer has made. It has also recorded when the changes were made.
Though these widely used source control tools of the prior art have proved to be apt for version controlling a number of NT workstations. There is presently, however, no way to adequately version control applications when they are built onto a larger type of computer. One example of such a computer is what is known as and commercially available as a Tandem™.
These types of larger computing devices may have a number of servers which accomplish its computing functions. They may also have a number of controlling processes, each of which manages a particular environment therein. With respect to the Tandem™, a Pathmon™ process, or a “pathway” is a controller for a particular environment.
Before the present invention, there was no way to ensure that applications being tested on a Tandem™ could be easily rebuilt—that the computing objects could be built from scratch—and that the objects being tested were kept up to date at all times.
Conventionally, one using a PC or in an NT network would have difficulty generating a build from CVS onto a Tandem. This process would involve manually checking the version out of CVS using a tag. After the version of the application was drawn out of CVS onto the PC, it would have to be manually transmitted to the Tandem using a File Transfer Protocol (FTP). Once on the Tandem, the process controller for the particular environment would have to be manually programmed to build the application in a directory on the Tandem. This involves transmitting updates into the process controller. This updates method is problematic, because there will be no guarantee that you can build the application again from scratch. You will not have the assurance that you can rebuild it if you have to. Additionally, knowledge of the vintage server classes will be retained, which would be problematic. If we end the development cycle on a particular application and then later on decide to expand on it, and all our environments are gone, then we will be precluded from rebuilding the application from the ground up. Additionally, this conventional process is very time consuming and labor intensive.
With the prior art techniques, environments were driven off of a process controller in the second computing device. The controller on the second computing device was given an ID. That ID was then used to set up specific environments.
Conventionally, the process controller (e.g., Pathmon™) on the Tandem™ contained the server class configurations. You would dump these configurations out onto a file, however, that file has established configurations for the particular environment in which its server class exists. In order to move it to a new environment, you would have to manually change the file so that you could make it work in another environment. This would involve reloading and testing the file to make sure that your changes were correct. This is a difficult thing to do, because there is nothing in the file that indicates which items are environmentally dependent, and which items are not. Thus, the programmer would have to painstakingly search and sort.
Additionally, this conventional method involves rebuilding the application one server class at a time. This involved recoding a file for every server class rebuilt, which is time consuming and very detail sensitive.
Another disadvantage in the prior art methods of building applications onto the large computer involves a lack of adaptability. Working on separate instances of the application in separate environments may become problematic where both instances are writing or working with the same set of tables.